React Native: Add Swift Package Manager support - #1076

Summary:
After community feedback from this one powersync-ja/powersync-js#1076 we've decided to fix the issue of clashing name constants - to avoid the SwiftPM pipeline scaffolding packages that collides with built-in packages.

This PR is the first step fixing this - refactoring the names of internal packages into constants.

## Changelog:

[IOS] [FIXED] - Created constants for internal SwiftPM packages so that we can create guards to avoid collisions

Pull Request resolved: #58035

Test Plan: ✅ Unit tests

Reviewed By: Abbondanzo

Differential Revision: D116936194

Pulled By: cipolleschi

fbshipit-source-id: 2882e512489cc4784a09aeb03769e97d64d286f7

Summary:
When saving settings in `react-native.config.js`, we should support all styles of exported data:

```js
module.exports = { spm: { name: 'worklets' } };   // old style
export const spm = { name: 'worklets' };          // new style, with a label
export default { spm: { name: 'worklets' } };     // new style, no label — "just this"
```

We only read the two first in the SwiftPM pipeline, silently ignoring anything written with `export default`.

This PR fixes this by adding a catch that tries to decode the default export.

Fixed after community feedback here: powersync-ja/powersync-js#1076

## Changelog:

[IOS] [FIXED] - SwiftPM pipeline now reads react-native.config.js with default exports correctly

Pull Request resolved: #58034

Test Plan: ✅ Added and ran unit tests.

Reviewed By: christophpurrer

Differential Revision: D116935856

Pulled By: cipolleschi

fbshipit-source-id: 7ebf7af3b3aaee2ffb506f94a15fabc244a4db30

Summary:
The scaffolder derived every target name with `toSwiftName(dep.name)`, ignoring the `spm.name` override in the library's own react-native.config.js.

A library setting that override got a manifest whose product name differed from the name the autolinker registers it under, and SPM failed resolution on `.product(name: "X", package: "X")` — the exact mismatch the override exists to prevent.

This setting is documented - but not followed up in the implementation.

Use the name the autolinker already resolved (`dep.swiftName`), falling back to `toSwiftName` when a caller runs the translation without it. Sibling references resolve the same way, through the new `SpmScaffoldSpec.siblingSwiftNames`.

Fixed after community feedback here: powersync-ja/powersync-js#1076

## Changelog:

[IOS] [FIXED] - Fixed not reading spm.name from react-native.config.js when scaffolding the Swift manifest

Pull Request resolved: #58033

Test Plan: ✅ unit tests

Reviewed By: zeyap

Differential Revision: D116794063

Pulled By: cipolleschi

fbshipit-source-id: 8b2f204efbc4d7537839ccef5b90cf4eba0d27bf

Summary:
A dependency's Swift name is derived from its npm package name with the scope dropped, which makes two collisions unavoidable: `powersync/react-native` derives `ReactNative`, one of React Native's own names, and `a/foo` and `b/foo` both derive `Foo`.

Either was emitted into the package graph as-is, and SwiftPM then failed deep inside dependency resolution with a duplicate-name error that named neither the library nor the react-native.config.js that caused it.

This was seen in the PR here powersync-ja/powersync-js#1076 - and was hard to fix.

This PR fixes this by adding support for prefixing the name with the scope if the name without scope crashes.

In addition the same logic is added when two packages have names that collide with each other.

If the name given by the SwiftPM scaffolder doesn't work for you - you can use the `spm.name` field in the `react-native.config.js` file to set a specific name (see SwiftPM docs).

## Changelog:

[IOS] [FIXED] - Resolve Swift manifest naming collisions

Pull Request resolved: #58044

Test Plan: ✅ Unit tests green

Reviewed By: mdvacca, cortinico

Differential Revision: D117178818

Pulled By: cipolleschi

fbshipit-source-id: 23269f4d959b84ac484be1911e8a863c74008ff9

Summary:
After community feedback from this one powersync-ja/powersync-js#1076 we've decided to fix the issue of clashing name constants - to avoid the SwiftPM pipeline scaffolding packages that collides with built-in packages.

This PR is the first step fixing this - refactoring the names of internal packages into constants.

## Changelog:

[IOS] [FIXED] - Created constants for internal SwiftPM packages so that we can create guards to avoid collisions

Pull Request resolved: #58035

Test Plan: ✅ Unit tests

Reviewed By: Abbondanzo

Differential Revision: D116936194

Pulled By: cipolleschi

fbshipit-source-id: 2882e512489cc4784a09aeb03769e97d64d286f7
(cherry picked from commit d36aa49)

Summary:
When saving settings in `react-native.config.js`, we should support all styles of exported data:

```js
module.exports = { spm: { name: 'worklets' } };   // old style
export const spm = { name: 'worklets' };          // new style, with a label
export default { spm: { name: 'worklets' } };     // new style, no label — "just this"
```

We only read the two first in the SwiftPM pipeline, silently ignoring anything written with `export default`.

This PR fixes this by adding a catch that tries to decode the default export.

Fixed after community feedback here: powersync-ja/powersync-js#1076

[IOS] [FIXED] - SwiftPM pipeline now reads react-native.config.js with default exports correctly

Pull Request resolved: #58034

Test Plan: ✅ Added and ran unit tests.

Reviewed By: christophpurrer

Differential Revision: D116935856

Pulled By: cipolleschi

fbshipit-source-id: 7ebf7af3b3aaee2ffb506f94a15fabc244a4db30
(cherry picked from commit ed76640)

Summary:
The scaffolder derived every target name with `toSwiftName(dep.name)`, ignoring the `spm.name` override in the library's own react-native.config.js.

A library setting that override got a manifest whose product name differed from the name the autolinker registers it under, and SPM failed resolution on `.product(name: "X", package: "X")` — the exact mismatch the override exists to prevent.

This setting is documented - but not followed up in the implementation.

Use the name the autolinker already resolved (`dep.swiftName`), falling back to `toSwiftName` when a caller runs the translation without it. Sibling references resolve the same way, through the new `SpmScaffoldSpec.siblingSwiftNames`.

Fixed after community feedback here: powersync-ja/powersync-js#1076

## Changelog:

[IOS] [FIXED] - Fixed not reading spm.name from react-native.config.js when scaffolding the Swift manifest

Pull Request resolved: #58033

Test Plan: ✅ unit tests

Reviewed By: zeyap

Differential Revision: D116794063

Pulled By: cipolleschi

fbshipit-source-id: 8b2f204efbc4d7537839ccef5b90cf4eba0d27bf
(cherry picked from commit 482acee)

Summary:
A dependency's Swift name is derived from its npm package name with the scope dropped, which makes two collisions unavoidable: `powersync/react-native` derives `ReactNative`, one of React Native's own names, and `a/foo` and `b/foo` both derive `Foo`.

Either was emitted into the package graph as-is, and SwiftPM then failed deep inside dependency resolution with a duplicate-name error that named neither the library nor the react-native.config.js that caused it.

This was seen in the PR here powersync-ja/powersync-js#1076 - and was hard to fix.

This PR fixes this by adding support for prefixing the name with the scope if the name without scope crashes.

In addition the same logic is added when two packages have names that collide with each other.

If the name given by the SwiftPM scaffolder doesn't work for you - you can use the `spm.name` field in the `react-native.config.js` file to set a specific name (see SwiftPM docs).

[IOS] [FIXED] - Resolve Swift manifest naming collisions

Pull Request resolved: #58044

Test Plan: ✅ Unit tests green

Reviewed By: mdvacca, cortinico

Differential Revision: D117178818

Pulled By: cipolleschi

fbshipit-source-id: 23269f4d959b84ac484be1911e8a863c74008ff9
(cherry picked from commit 962aeec)

…58035)

Summary:
After community feedback from this one powersync-ja/powersync-js#1076 we've decided to fix the issue of clashing name constants - to avoid the SwiftPM pipeline scaffolding packages that collides with built-in packages.

This PR is the first step fixing this - refactoring the names of internal packages into constants.

## Changelog:

[IOS] [FIXED] - Created constants for internal SwiftPM packages so that we can create guards to avoid collisions

Pull Request resolved: react#58035

Test Plan: ✅ Unit tests

Reviewed By: Abbondanzo

Differential Revision: D116936194

Pulled By: cipolleschi

fbshipit-source-id: 2882e512489cc4784a09aeb03769e97d64d286f7

…t#58034)

Summary:
When saving settings in `react-native.config.js`, we should support all styles of exported data:

```js
module.exports = { spm: { name: 'worklets' } };   // old style
export const spm = { name: 'worklets' };          // new style, with a label
export default { spm: { name: 'worklets' } };     // new style, no label — "just this"
```

We only read the two first in the SwiftPM pipeline, silently ignoring anything written with `export default`.

This PR fixes this by adding a catch that tries to decode the default export.

Fixed after community feedback here: powersync-ja/powersync-js#1076

## Changelog:

[IOS] [FIXED] - SwiftPM pipeline now reads react-native.config.js with default exports correctly

Pull Request resolved: react#58034

Test Plan: ✅ Added and ran unit tests.

Reviewed By: christophpurrer

Differential Revision: D116935856

Pulled By: cipolleschi

fbshipit-source-id: 7ebf7af3b3aaee2ffb506f94a15fabc244a4db30

…58033)

Summary:
The scaffolder derived every target name with `toSwiftName(dep.name)`, ignoring the `spm.name` override in the library's own react-native.config.js.

A library setting that override got a manifest whose product name differed from the name the autolinker registers it under, and SPM failed resolution on `.product(name: "X", package: "X")` — the exact mismatch the override exists to prevent.

This setting is documented - but not followed up in the implementation.

Use the name the autolinker already resolved (`dep.swiftName`), falling back to `toSwiftName` when a caller runs the translation without it. Sibling references resolve the same way, through the new `SpmScaffoldSpec.siblingSwiftNames`.

Fixed after community feedback here: powersync-ja/powersync-js#1076

## Changelog:

[IOS] [FIXED] - Fixed not reading spm.name from react-native.config.js when scaffolding the Swift manifest

Pull Request resolved: react#58033

Test Plan: ✅ unit tests

Reviewed By: zeyap

Differential Revision: D116794063

Pulled By: cipolleschi

fbshipit-source-id: 8b2f204efbc4d7537839ccef5b90cf4eba0d27bf

Summary:
A dependency's Swift name is derived from its npm package name with the scope dropped, which makes two collisions unavoidable: `powersync/react-native` derives `ReactNative`, one of React Native's own names, and `a/foo` and `b/foo` both derive `Foo`.

Either was emitted into the package graph as-is, and SwiftPM then failed deep inside dependency resolution with a duplicate-name error that named neither the library nor the react-native.config.js that caused it.

This was seen in the PR here powersync-ja/powersync-js#1076 - and was hard to fix.

This PR fixes this by adding support for prefixing the name with the scope if the name without scope crashes.

In addition the same logic is added when two packages have names that collide with each other.

If the name given by the SwiftPM scaffolder doesn't work for you - you can use the `spm.name` field in the `react-native.config.js` file to set a specific name (see SwiftPM docs).

## Changelog:

[IOS] [FIXED] - Resolve Swift manifest naming collisions

Pull Request resolved: react#58044

Test Plan: ✅ Unit tests green

Reviewed By: mdvacca, cortinico

Differential Revision: D117178818

Pulled By: cipolleschi

fbshipit-source-id: 23269f4d959b84ac484be1911e8a863c74008ff9